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DETAILED ACTION 

1 . Claims 1-30 are subject to examination. 



Response to Arguments 
2. Applicant's arguments filed 1/27/2006, pages 8-14 have been fully considered but 
they are not persuasive. Therefore, rejection of claims 1-30 is maintained. 

Applicant argues (1), limitations rejected under 112 first paragraph, " assigning a 
virtual IP address to a scheduler ", is supported by page 7, lines 4-6, of the specification, 
i.e., the first item (Single virtual IP address for many Web servers ) is supported by all 
local load balancers. All load balancers publish a Virtual IP (VIP) address to the world 
and then have many machines which can take traffic for that IP address", hence the 
rejection should be withdrawn. 

The examiner respectfully disagrees in response to applicant's arguments. 
Contrary to applicant's assertions, the limitations " assigning a virtual IP address to a 
scheduler ", are neither supported by the page 7, lines 4-6, of the specification nor 
supported by the other portions of the specification containing virtual IP address related 
information. The additional limitations, assigning the virtual IP address to a particular 
scheduler that supports other limitations of the claims, for example see claim 1, is not 
similar to "the first item (Single virtual IP address for many Web servers) is supported by 
all local load balancers . All load balancers publish a Virtual IP (VIP) address to the world 
and then have many machines which can take traffic for that IP address", as the 
specification do not show how an assignment of the virtual IP address to a scheduler is 
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performed that implements other limitations of the cliams. Hence, the rejection is 
maintained. 

Applicant argues (2), "none of the cited art teach or suggest limitations, all 
incoming packets from requesting clients destined for the load balancing array are routed 
through the scheduler" and "Bruck et al, 6,80 1,949, Rainfmity Inc (Hereinafter Bruck- 
Rainfinity) does not teach or disclose assigning a virtual IP address to a scheduler that is 
designated as active scheduler for a load balancing array". 

The examiner respectfully disagrees in response to applicant's arguments. The 
amended (newly presented) limitations, " all incoming packets from requesting clients 
destined for the load balancing array are routed through the scheduler", is also taught by 
Zisapel et al., US Publication, 2002/0103846 Al, Aug. 1, 2002, "Load Balancing" 
(Hereinafter Zisapel-Radware), e.g., LB1 load balancing server also scheduling client 
requests for LB2 load balancing server, figures 1 A - 1C, paragraphs 33 and 34, page 3. 
Note: the claimed limitations, "all incoming packets from requesting clients", is not 
limited to all incoming packets belong to all the claimed requesting clients, and not 
including just one of the requesting clients. The limitations, " incoming packets", is not 
limited to packets incoming to the load balancing array and/or the scheduler. 

In response to applicant's arguments for "assigning a virtual IP address to a 
scheduler that is designated as active scheduler for a load balancing array", against the 
references individually, one cannot show nonobviousness by attacking references 
individually where the rejections are based on combinations of references. See In re 
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Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 
231 USPQ 375 (Fed. Cir. 1986). The limitations are rejected using combine teachings of 
Zisapel-Radware, Hassett et al., 6173,31 1, PointCast Inc (Hereinafter Hasett-PointCast) 
and Bruck-Rainfinity. Bruck-Rainfinity discloses the relied upon limitations i.e., the 
concept of assigning a virtual IP address to a scheduling object (e.g., col., 36, line 26 - 
col., 37, line 19) and usage of the virtual IP address (e.g., col., 36, line 26 - col., 37, line 
19), as claimed. Further, the claims do not define how the virtual IP address is different 
than the cited references. The specification of this application, page 24, lines 21 -24, 
clearly states, "Although the invention is described herein with reference to the preferred 
embodiment, one skilled in the art will readily appreciate that other applications may be 
substituted for those set forth herein without departing from the spirit and scope of the 
present invention. Accordingly, the invention should only be limited by the claims 
included below". Since, applicant's claims contain broadly claimed subject matter, it 
clearly reads upon the examiner's interpretation of the claimed subject matter. Therefore, 
the rejection is maintained. 

Response to Amendment 

3. The amendment filed 5/6/2005 is objected to under 35 U.S.C. 132 because it 
introduces new matter into the disclosure. 35 U.S.C. 132 states that no amendment shall 
introduce new matter into the disclosure of the invention. The added material which is 
not supported by the original disclosure is as follows: (Note: this rejection is maintained 
from office action, dated 7/27/2005). 
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a. addition of limitations, "assigning a virtual IP address to a scheduler", in 
claims 1 and 16. 

Applicant is required to cancel the new matter, to avoid abandonment of this 
application, in the reply to this Office Action. 



Claim Rejections - 35 USC § 112 
The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

4. Claims 1 and 16 are rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the written description requirement. The claim(s) contains subject matter, 
which was not described in the specification in such a way as to reasonably convey to one 
skilled in the relevant art to use and/or make the invention. 

The specification does not contain subject matter to implement limitations, 
"assigning a virtual IP address to a scheduler ", as cited in claims 1 and 16. Also, page 7, 
lines 22-30, of the specification, states "single virtual IP address for many Web servers", 
which has a different scope than the claimed limitations. 

Examiner has reviewed the specification and OCR whole document and could not 
find support for the additional limitations as claimed. (Note: this rejection is maintained 
from office action, dated 7/27/2005). 



Claim Rejections - 35 USC § 103 
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5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1, 2, 16 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Zisapel-Radware in view of Hasett-PointCast and Bruck-Rainfinity. 

7. As per claims 1 and 16, Zisapel-Radware clearly teaches a process and an 
apparatus (e.g., figure 1C, abstract) to implement routing packets through a load 
balancing array of servers across a network in a computer environment (e.g., router 
balancing load among cluster of servers over the network, figures 1 A - 1C, paragraph 33, 
page 3), 

a scheduler that is designated as active scheduler for a load balancing array (e.g., 
usage of load balancing servers, content servers, SI, Sn, figures 1A - 1C, paragraph 33, 
page 3); 

wherein all incoming packets from requesting clients destined for the load 
balancing array are routed through said scheduler (e.g., LB1 load balancing server also 
scheduling client requests for LB2 load balancing server, figures 1 A - 1C, paragraphs 33 
and 34, page 3); 

wherein said scheduler routes and load balances a request packet from a 
requesting client (e.g., client requests, paragraphs 33 and 34, page 3) to a load balancing 
server (e.g., LB1 load balancing server also scheduling client requests for LB2 load 
balancing server, figures 1 A - 1C, paragraph 33, page 3); 
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wherein said load balancing server routes and load balances said request packet to 
a back end Web server (e.g., LB2 load balancing server balancing load among content 
servers, SI, Sn, figures 1 A - 1C, paragraph 33, page 3); 

wherein said back end Web server's response packet to said request packet is sent 
to said load balancing server (e.g., SI, Sn, content servers supporting client requests 
through LB2 load balancing server, paragraphs 8-10, pagel); and 

wherein said load balancing server sends said response packet directly to said 
client (e.g., LB2 load balancing server forwarding response from content servers, SI, Sn, 
to the clients, paragraphs 8-10, pagel). 

Zisapel-Radware also teaches handling of multiple requests for a client (e.g., 
paragraph 36, page 3). 

However, Zisapel-Radware does not specifically mention about a request 
containing multiple packets and a scheduler supporting multiple clients . 

Hasett-PointCast clearly teaches a request containing multiple packets (e.g., 
abstract, col., 7, lines 5 - 40, col, 3, lines 34 - 65) and a scheduler supporting multiple 
clients (e.g., abstract, col., 7, lines 5 - 40, col., 3, lines 34 - 65). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware with Hasett-PointCast 
in order to facilitate the scheduler to support multiple clients because the requests from 
the multiple clients would be processed by the scheduler. A request having multiple 
packets would help the request communicated from a client to the scheduler. The 
scheduler would receive requests from the clients and would forward the requests so that 
the requests from the clients are properly handled. 
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Zisapel-Radware and Hasett-PointCast do not specifically mention about 
assigning a virtual IP address to scheduling object and usage of the virtual IP address. 

Bruck-Rainfinity discloses the concept of assigning a virtual IP address to 
scheduling object (e.g., col., 36, line 26 - col., 37, line 19) and usage of the virtual IP 
address (e.g., col., 36, line 26 - col., 37, line 19). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware and Hasett-PointCast 
with Bruck-Rainfinity in order to facilitate assigning a virtual IP address to scheduling 
object and usage of the virtual IP address because the scheduling object would use the 
virtual IP address for communicating information to a remote device. The assigned 
virtual IP address would provide a client device to use the object device for processing 
the request. 

8. As per claims 2 and 17, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
teach the claimed limitations as rejected above. Zisapel-Radware also teaches the 
following: 

scheduler is a load balancing server and routes and load balances client requests 
to itself (e.g., LB1 load balancing server scheduling client requests for itself, figures 1 A - 
1C, paragraph 33, page 3). 

9. Claims 3, 4, 7, 8, 13, 18, 19, 22, 23 and 28 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in view 
of "Official Notice". 
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10. As per claims 3 and 18, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
teach the claimed limitations as rejected above. Zisapel-Radware also discloses electing 
a load balancing server (e.g., selection of LB1 or LB2 or LB3, paragraphs 33 and 42) 
among a plurality of load balancing servers (e.g., LB1 or LB2 or LB3, paragraphs 33 and 
42) as a new scheduler (e.g., usage of LB1 or LB2 or LB3 upon availability for new 
(next) scheduling, paragraphs 33 and 42). (Note: the new scheduler is not limited to 
replacing another scheduler). 

However, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity do not 
specifically mention about the use of detecting the failure of the server. "Official Notice" 
is taken that both the concept and advantages of providing to detect the failure of the 
server is well known and expected in the art. For example, Coile et al., 6,108,300 
(Hereinafter Coile) teaches these limitations, e.g., col, 5, lines 3 - 24, e.g., col, 6, lines 
40 -62, col., 8, lines 2 -28. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include detecting the failure of the server with the teachings of 
Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in order to facilitate handling of 
system performance in an event of the scheduler failure because upon failure of the 
scheduler the system would know what client requests are not handled by the failed 
scheduler. The system would have another server to handle the job of the failed server. 

11. As per claims 4 and 1 9, Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity 
teach the claimed limitations as rejected above. However, Zisapel-Radware, Hasett- 
PointCast and Bruck-Rainfinity do not specifically mention about the use of server 
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detecting the failure of other load balancing servers and the server stops routing packets 
to any failed load balancing servers. "Official Notice" is taken that both the concept and 
advantages of providing server detecting the failure of other load balancing servers and 
the server stops routing packets to any failed load balancing servers, is well known and 
expected in the art. For example, Coile et al., 6,108,300 (Hereinafter Coile) teaches 
limitations, "server detecting the failure of other load balancing servers (e.g., col., 12, 
lines 35 - 54, col., 6, lines 40 - 62, col, 8, lines 2 - 28)" and "the server stops routing 
packets to any failed load balancing servers/back end Web servers (e.g., col., 12, lines 35 
- 54, e.g., col., 6, lines 40 - 62, col., 8, lines 2 - 28)". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include server detecting the failure of other load balancing servers 
and the server stops routing packets to any failed load balancing servers, with the 
teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in order to 
facilitate assigning client requests to another load balancing server instead of the failed 
load balancing server because stopping to route packets to the failed load balancing 
server would prevent dropping packets. Rerouting to the packets to the other load 
balancing server will help process the client requests. 

12. As per claims 7, 8, 22 and 23, Zisapel-Radware, Hasett-PointCast and Bruck- 
Rainfinity teach the claimed limitations as rejected above. However, Zisapel-Radware, 
Hasett-PointCast and Bruck-Rainfinity do not specifically mention about the use of 
server decrypting and encrypting packet for an SSL session. "Official Notice" is taken 
that both the concept and advantages of providing server decrypting and encrypting 
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packet for an SSL session, is well known and expected in the art. For example, 
Hankinson et al., 6,799,202 (Hereinafter Hankinson) teaches limitations, "server 
decrypting and encrypting packet for SSL session (e.g., col., 3, lines 2 - 65)". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include server decrypting and encrypting packet for an SSL 
session, with the teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in 
order to facilitate secure communicating between the client and the Web server because 
for processing and forwarding the packet to the Web server, the load balancing server 
will decrypt the packet when it receives from the client. The load balancing server will 
receive the response packet from the Web server, and it will encrypt the response packet 
before sending to the client. Using well-known SSL session implementation, the web 
server and the client will have direct secure communication. 

13. As per claims 13 and 28, Zisapel-Radware, Hasett-PointCast and Bruck- 
Rainfinity teach the claimed limitations as rejected above. However, Zisapel-Radware, 
Hasett-PointCast and Bruck-Rainfinity do not specifically mention about the use of 
detecting and stop routing request packets to failed back end Web servers. "Official 
Notice" is taken that both the concept and advantages of providing detecting and stop 
routing request packets to failed back end Web servers is well known and expected in the 
art. For example, Coile et al., 6,108,300 (Hereinafter Coile) teaches limitations* "server 
detecting the failure of other load balancing servers (e.g., col, 12, lines 35 - 54, col., 6, 
lines 40 - 62, col., 8, lines 2 - 28)" and "the server stops routing packets to any failed 
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load balancing servers/back end Web servers (e.g., col., 12, lines 35 - 54, e.g., col., 6, 
lines 40 - 62, col., 8, lines 2 - 28)". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include detecting and stop routing request packets to failed back 
end Web servers with the teachings of Zisapel-Radware, Hasett-PointCast and Bruck- 
Rainfinity in order to facilitate accessing the other web server in an event of the web 
server failure because upon failure of the web server, other web server would help 
support the client requests. By stopping to route the packets to the failed web server 
would help prevent packets from dropping and the other web server would then handle 
the client requests. 

14. Claims 5, 6, 14, 15, 20, 21, 29, 30, are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in view of 
Masters 6,374,300 (Hereinafter Masters). 

15. As per claims 5, 6, 14, 15, 20, 21, 29, 30, Zisapel-Radware, Hasett-PointCast and 
Bruck-Rainfinity teach the claimed limitations as rejected above. However, Zisapel- 
Radware, Hasett-PointCast and Bruck-Rainfinity do not specifically mention about the 
server scheduling sessions to servers based on a cookie or session ID and use of cookie 
injection to map a client to a specific server. 

Masters clearly teaches about the concept of server scheduling sessions to servers 
based on a cookie or session ID (e.g., abstract, col., 10, lines 8-61), and use of cookie 
injection to map a client to a specific server (e.g., abstract, col., 10, lines 8-61, col, 13, 
lines 1- 24), modify URLs in the HTML page in a packet to serve them from said content 
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delivery network (e.g., col., 5, linesl4 - 61, col., 3, lines 21 - 50), HTML pages that have 
modified URLs are cached to improve performance (e.g., abstract, col., 10, lines 8-61, 
col., 2, lines 24 - page 4, line 34, col., 7, lines 1-16). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware, Hasett-PointCast and 
Bruck-Rainfinity with Masters in order to facilitate scheduling based on cookie for 
persistent connection with the web server because using the cookie the client request can 
be routed to a previously selected destination web server associated with the client. The 
client will be able to continue using the same web server support. As per Masters 
teachings, the cookie information can be manipulated as necessary. Hence, the client will 
be able to continue communicating with the server in a direct persistent manner. 

16. Claims 9-12, 24-27, are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Zisapel-Radware, Hasett-PointCast, Bruck-Rainfinity and "Official Notice" in view 
of Masters 6,374,300 (Hereinafter Masters). 

17. As per claims 9-12, 24-27, Zisapel-Radware, Hasett-PointCast and Bruck- 
Rainfinity teach the claimed limitations as rejected above. However, Zisapel-Radware, 
Hasett-PointCast and Bruck-Rainfinity do not specifically mention about the client 
keeping connection alive with the server. "Official Notice" is taken that both the concept 
and advantages of the client keeping connection alive with server, is well known and 
expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include the client keeping connection alive with the server, with 



Application/Control Number: 09/779,07 1 Page 1 4 

Art Unit: 2154 

the teachings of Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity in order to 
facilitate secure communicating between the client and the Web server because using 
well-known SSL session implementation, the web server and the client will have direct 
secure communication as long as the connection between the web server and the client is 
alive. 

Zisapel-Radware, Hasett-PointCast and Bruck-Rainfinity do not specifically 
mention about URL based scheduling of packets and the load balancing server 
performing hash scheduling of packets. Masters teaches about URL based scheduling of 
packets (e.g., col, 5, lines 18 - 65), persistent connections in its paths when required 
(e.g., col., 5, lines 22 - 59, col., 6, lines 8-31) and the load balancing server performing 
hash scheduling of packets (e.g., col., 15, lines 45 - col., 16, lines 21) and uses hash 
group based persistence to maintain its persistence tables (e.g., col., 5, lines 22 - 59, col., 
15, line 57 -col., 16, line 24). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware, Hasett-PointCast and 
Bruck-Rainfinity with Masters in order to facilitate secure communicating between the 
client and the Web server because the URL information in the https packet would provide 
information of the resource, which the client needs to access. The scheduling with 
hashing of packets will provide direct secure communication between the web server and 
the client. 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of 
time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than 
SIX MONTHS from the mailing date of this final action. 

Examiner has cited particular columns and line numbers and/or paragraphs and/or 
sections and/or page numbers in the reference(s) as applied to the claims above for the 
convenience of the applicant. Although the specified citations are representative of the 
teachings of the art and are applied to the specific limitations within the individual claim, 
other passages and figures may apply as well. It is respectfully requested from the 
applicant in preparing responses, to fully consider the references in entirety, as potentially 
teaching, all or part of the claimed invention, as well as the context of the passage, as 
taught by the prior art or disclosed by the Examiner. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone number is (571) 272-3973. 
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The examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 
10:00 am to 8:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number 
for the organization where this application or proceeding is assigned is (571) 273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 



Haresh Patel 
April 12, 2006 



JOHN FOLLANSBEE 
iP^ViSDg^PATENT EXAMINER 
^CHNOLOGY CENTER 2100 



